Make the leader write crash-consistent and close the liveness holes
found in review:

* Run the leader span (seal win -> DWB_FSYNCED broadcast) as a critical
  section: an I/O error there cannot be unwound - the seal winner is the
  only process able to advance the batch - so it now escalates to PANIC
  instead of leaving the batch, its waiters and its staging buffer
  wedged forever.  Everything that may fail harmlessly (the one-time
  leader allocations, the batch file VFD, the backend's condition-
  variable wait event set) moves into a pre-seal prepare phase, where an
  ERROR leaves the batch ALLOCATED for another writer to seal later.

* Pin the batch with a leader ref from SEAL to FSYNCED: a sealed batch
  can no longer drop to zero refs before it is durable, so the
  FSYNCED -> RETIRING hand-off always has exactly one owner, even when
  every writer exits during the write.

* Guard the seg_set dedup scan with the batch's publish_lock LWLock
  instead of a spinlock (the O(n) scan far exceeds the spinlock
  hold-time rule); drop the seg_lock field.

* Reserve the staging buffer before taking DWBRingOpenLock, leaving no
  sleeping or interruptible point while a batch is held out of
  DWB_FREE.

* Assorted hardening: ConditionVariableCancelSleep after wait loops, a
  hard ERROR on pendingRefs overflow, batch_id assertions in the
  writer-side API, uint16 slot_flags to match the on-disk width,
  StaticAssertDecl pins on the on-disk struct layout, canonical
  read-error reporting, ssize_t for FileWrite results, a symbolic GUC
  maximum for dwb_batch_pages, and comments aligned with the Stage 1
  reality.

* test_dwb: prove CRC rejection by flipping bytes in a batch file,
  exercise both DWBProcExit paths with a backend dying mid-batch (the
  orphan scenario is a direct regression test for the leader pin),
  refuse-start coverage for dwb_batch_pages, and tighter bounds.

The "has the open batch already been replaced" guard compared only the
ring index.  Indexes are reused quickly on a small ring, so a slow
opener - one that bounced off a sealed batch and then slept, e.g. in
the pre-lock staging-buffer wait - could arrive while open_batch_idx
named the SAME index again, now holding a NEW live incarnation.  The
index-only comparison passed, the opener repointed open_batch_idx to a
fresh batch, and the live incarnation was orphaned in ALLOCATED
together with its staging buffer: nothing ever seals an unreachable
batch, writers waiting on it hang, and a writer blocked there while
holding an unpublished reservation in the next batch eventually drives
that batch's leader into the coverage-wait PANIC.  The concurrent TAP
stress hit this in the majority of runs.

Replace the guard with the exact criterion, evaluated under
DWBRingOpenLock: the open batch needs replacing if and only if its
SEAL_BIT is set.  SEAL_BIT is set at SEAL and stays set through FREE;
only the reopen re-initialization - under this same lock - clears it.
A live reopened incarnation at the same index therefore reads as "bit
clear" and the stale opener backs off; if the new incarnation has
itself been sealed meanwhile, replacing it is correct no matter which
incarnation the caller bounced off.  Comparing batch ids instead would
require capturing a non-atomic uint64 outside the lock (a torn-read
window on 32-bit platforms) and plumbing it through the API.

Add test_dwb_open_stale(): a deterministic single-backend regression
that replays the losing interleaving without any timing dependence -
cycle once so open_batch_idx names a sealed-and-retired index, reopen
the same index as a live incarnation by acquiring one slot, then call
DWBOpenNewBatch with the stale index and assert the pointer is
untouched.  With the index-only guard the test fails every run;  the
organic stress race fires only probabilistically.  DWBOpenNewBatch is
exported non-static solely for this test.

No caller in any planned stage: the apply-pass and ring re-creation run
in the startup process before any backend exists, and the batch-file
VFD caches of leaders and retire workers are torn down by fd.c at
process exit anyway.

FlushBuffer now stages every BM_PERMANENT page into the double write
buffer before smgrwrite: DWBStagePageWrite makes the private copy durable
in pg_dwb/, DWBFinishPageWrite releases the batch ref afterwards, with an
optional smgrwriteback in between (dwb_writeback) so the retirement fsync
becomes a cheap barrier.  Writers are classified by process role into the
eviction and background (checkpointer, bgwriter) classes with separate
open batches; background opens keep DWB_EVICT_RESERVE free batches for
user evictions.

Retirement is driven by the new segment->batch back-reference hash
(DWSegmentHash): the last batch ref publishes the seg_set under the
batch's publish_lock, and any segment fsync clears the bits it had
snapshotted before starting, guarded against ring-index reuse by
re-checking batch_id under the same lock.  Fsyncs come from three
independent sources sharing that accounting: a pool of dwb_retire_workers
background workers (partitioned proactive sweeps, force-seal of timed-out
batches), ProcessSyncRequests in the checkpointer (wrapped around each md
segment fsync), and writers stuck on a full ring sweeping synchronously
as self-service.  A hash overflow degrades to a synchronous per-batch
retire instead of wedging the ring.

Sealing is decentralized: a writer whose ref is the only one on a
still-open batch seals immediately (a lone sequential flush stream would
otherwise pay dwb_batch_timeout_ms per page), a waiter seals after that
timeout, and the workers back-stop batches whose writers all died.  This
keeps the write path fully functional with no worker pool at all
(dwb_retire_workers = 0, single-user mode, shutdown checkpoint after the
workers are gone).

Refs are now attached to the ResourceOwner and released before the
buffer-IO cleanup: an abandoned ref whose batch is already durable
repairs its data page from the batch file while BM_IO_IN_PROGRESS is
still held, closing the window where a half-done smgrwrite could leave a
torn page behind a recycling batch, without racing any concurrent flush.

Backpressure escalates in two stages clocked by retirement progress
(freed_events): a WARNING plus bgwriter pause, then dwb_on_stall, where
the checkpointer and the startup process always PANIC by explicit policy.
The dwb-force-stall injection point drives both TAP scenarios: a stalled
backend eviction fails with an ERROR while the cluster stays up, and a
stalled checkpointer PANICs into crash recovery.

pg_stat_io gains the "dwb" object (batch writes with bytes, fdatasyncs);
new wait events cover the worker main loop and batch-file reads.

…-up)

A review round over the Stage 2 commit surfaced one real corruption
path and two accounting leaks, all rooted in the assumption that a
retirement fsync failure is always a PANIC.  That only holds with the
default data_sync_retry = off; with data_sync_retry = on the process
survives the error and the bookkeeping used to rot:

* DWBSegmentFsyncBegin now unconditionally drops a leftover snapshot
  before deciding whether to take a new one.  Previously, after an
  fsync ERROR between Begin and End, the checkpointer kept the stale
  snapshot armed; the End of the next successful fsync of an unrelated
  non-MD tag (CLOG/SLRU share pendingOps) consumed it, decrementing
  the failed segment's back-references and freeing its batches without
  their data being durable -- silent corruption after a crash.

* DWBRetireSyncSegment no longer throws on a soft failure: it returns
  false (WARNING), the segment's bits stay for a later retry, and the
  caller's fsync_in_progress claim is always released.  The OOM retire
  path escalates to PANIC instead: nothing ever revisits a
  DWB_OOM_RETIRING batch, and the path can run inside a ResourceOwner
  release callback, which must not fail.

The proc-exit backstop now performs the abandoned-slot repair only for
refs that were attached to a ResourceOwner.  An owned ref alive at
proc-exit implies the same-owner buffer-IO resource is alive too (it
releases after the DWB ref within one owner, and DWBFinishPageWrite
precedes TerminateBufferIO on the success path), so BM_IO_IN_PROGRESS
is still ours and the repair is race-free; ownerless test refs never
had the interlock, so writing would race concurrent flushes.

Hardening: DWB_NUM_BATCHES_MAX ties the GUC maximum to the retire-side
snapshot array; static asserts pin the no-padding requirement of the
DWSegRef hash key and the semantic ordering of DWBatchState;
DWBAcquireSlot memsets the seg ref it publishes; DWBPublishBatchSegSet
asserts a non-empty seg_set.  Comment fixes: the DWBTrySealBatch
header no longer claims every seal funnels through it (the overflow
writer calls DWBSealBatch directly), and the FlushBuffer comment no
longer overstates PageSetChecksumCopy for all-zero new pages.

New test coverage:

* test_dwb_torn_repair stages a real table's block, tears it on disk
  and aborts: the ResourceOwner release must repair the block from the
  batch copy, verified by reading it back after a restart (001).
* 004_retire_paths.pl proves a CHECKPOINT alone retires a parked batch
  through the DWBSegmentFsyncBegin/End wrap (fsync = on is required:
  with fsync = off ProcessSyncRequests skips the whole per-file
  block), and overflows DWSegmentHash to exercise the synchronous OOM
  retire.
* 002 gains a dwb_retire_workers = 0 phase over a real eviction
  workload and an unlogged-bypass check that reads the ring content
  itself (test_dwb_ring_rel_slots) -- a normal CHECKPOINT skips
  unlogged buffers, so the shutdown checkpoint provides the flush.
* 003 walks a victim through Stage A into Stage B on the real stall
  clocks, with no injection point.
* 001 covers the DWB_EVICT_RESERVE boundary: a background-class fill
  stops with the reserve left free, an eviction-class fill drains it.
* meson.build now runs all four TAP files (002/003 were missing).

…ollow-up)

A cross-agent review round over the Stage 2 commits surfaced three
process-lifecycle and accounting defects, closed here together with the
regression coverage it asked for.

The exit backstop moves from on_proc_exit to before_shmem_exit.
Dropping the last ref of a durable batch publishes its seg_set under
publish_lock and DWBSegHashLock, which is only legal while the PGPROC
is alive -- on_proc_exit callbacks run after ProcKill, and LWLockAcquire
asserts a live PGPROC under a postmaster.  Because the backstop may now
run before the ResourceOwner release of the same refs, DWBAbandonRef
became idempotent: whichever side runs second finds in_use = false and
returns.  test_dwb_leak_fsynced pins the scenario: a session exits
holding the LAST ref of a DWB_FSYNCED batch, so the FSYNCED -> RETIRING
hand-off executes inside the exit callback itself.

The abandoned-slot repair path is now allocation-free.  It runs from
release callbacks that must not fail, but OpenTransientFile can ERROR
in reserveAllocatedDesc and PathNameOpenFile in its VFD bookkeeping.
DWBReadSlotImage opens the batch file itself with BasicOpenFile (no
allocations; recovers from EMFILE by closing LRU VFDs) and reads with
raw pg_pread under the DWB_BATCH_READ wait event; DWBRewriteAbandonedSlot
likewise switches to BasicOpenFile.  Every failure on the path, opens
and closes included, is a PANIC.

The retire worker pool now verifies that its workers actually fit.
RegisterBackgroundWorker only LOGs "too many background workers", so a
pool registered after the logical replication launcher could silently
come up short.  bgworker.c exposes GetNumRegisteredBackgroundWorkers()
-- counting only successful registrations; the previous pre-increment
also overcounted failed attempts -- and DWBRetireWorkersRegister FATALs
when dwb_retire_workers exceeds the slots that remain free.  A TAP test
asserts the refusal at max_worker_processes = 1.

pgstat_count_io_op_time() feeds pg_stat_database's blk_write_time /
blk_read_time only for relation and temp-relation objects now: the old
"anything but WAL" condition also counted DWB batch writes, doubling
the apparent block write time of a page that goes through the ring.

New data_sync_retry regression coverage in 004_retire_paths.pl:
test_dwb_stale_snapshot replays a checkpointer fsync ERROR between
DWBSegmentFsyncBegin/End followed by a successful non-MD sync -- the
parked batch must stay RETIRING; and a directory planted at a fake
segment's path makes the retire fsync fail with EISDIR under
data_sync_retry = on -- the sweep must not throw, the batch must stay,
and the segment must be coverable by the next sweep after the obstacle
is removed, proving the advisory claim was released.

All DWB typedefs are added to typedefs.list and the touched files are
pgindent-clean.

A complexity-focused review pass over the Stage 2 commits; behavior is
unchanged and the full test_dwb suite stays green.

* Drop the nPendingRefs counter: the free-slot scan in DWBAcquireSlot
  already knows whether the array is full, so the overflow guard moves
  after the scan and the counter bookkeeping disappears.

* Replace the hand-rolled bubble sort of RETIRING batches in
  DWBRetireSweep with qsort over a named DWBRetiringBatch struct and a
  pg_cmp_u64 comparator; batch ids are unique, so stability is not
  needed, and O(n^2) was pointless on 1024-batch rings.

* Deduplicate the test harness: make_tag() replaces nine copies of the
  RelFileLocator/InitBufferTag boilerplate, stage_one_page() is the
  shared acquire-publish-seal-wait prologue of the five single-page
  scenarios, and leak_refs() is the shared body of the leak and
  abort-release scenarios.  Upcoming checkpoint and apply-pass tests
  can reuse these instead of growing new copies.

Deliberately kept: the dwb-after-batch-fsynced injection point (the
hook for future apply-pass crash tests between the batch fsync and
smgrwrite) and DWBWriterClass() (the seam where flush-source
classification will grow).

io_torn_pages_protection now drives WAL full-page images through a
single derivation point, EffectiveFullPageWrites(): "double_writes" and
"off" force FPIs off, while "full_pages" keeps the legacy
full_page_writes GUC meaningful (external consumers such as pg_upgrade
still pass it).  Online backups keep forcing page images through the
vanilla runningBackups term of doPageWrites; repairing a page copied
mid-write into a backup is FPI replay's job, not the ring's.

The pg_dwb ring is local to an instance, so its contents are excluded
from base backups via excludeDirContents, which also converts a
symlinked pg_dwb into an empty real directory.  This is mirrored in
pg_rewind's filemap so a rewind never copies the source's ring over;
the target's own leftover ring stays inert thanks to the generation
bump on every start.

Checkpoints take no DWB barrier by design and needed no code; a new
004 scenario pins that a CHECKPOINT completes while an open ALLOCATED
batch is live and leaves it alone.  New TAP coverage: 005_standby.pl
(a standby cold-starts a fresh ring from a base backup, runs its own
ring during replay with the retire worker alive in recovery, survives
crashes on either side, promotes with a replay backlog and advances
minRecoveryPoint past replayed flushes) and 006_backup.pl (pg_waldump
shows no FPW outside a backup window and FPWs inside one; the backup
keeps pg_dwb as an empty directory with no warnings, including the
symlink layout; a restored cluster cold-starts a fresh generation).

…3 follow-up)

The per-class open batch pointer could keep naming a freed batch index
after the other class reopened it: open_batch_idx[] is only replaced
when its batch is sealed, and reservations did not check who owns the
current incarnation.  A checkpointer flush could then join a live
EVICTION batch and, on the no-pool path, seal it under the holder.
next_slot_idx now carries a writer-class bit stamped at re-init under
DWBRingOpenLock, reservations use a CAS that validates the seal and
class bits atomically with the increment (a blind fetch_add into a
foreign batch would leave a never-published slot and hang the leader's
coverage wait), and DWBOpenNewBatch treats a foreign-class incarnation
as needing replacement.  The checkpoint scenario in 004 reproduces the
aliasing deterministically and no longer needs its warmup choreography.

The rest closes gaps around WAL that carries no full-page images:

* pg_rewind now requires io_torn_pages_protection = "full_pages" (and
  full_page_writes = on) on a live source: pages read from a running
  server can be torn and only FPI replay repairs them, which
  double_writes WAL cannot provide.  Rewinding from a stopped source
  stays available.  New 007_rewind.pl also pins that the rewind wipes
  the target's own ring and the rewound node cold-starts a fresh one.

* A mode change through a restart emits no XLOG_FPW_CHANGE (the
  end-of-recovery UpdateFullPageWrites call is gated on recovery being
  finished), so the standby backup guards never saw the transition and
  a backup taken before the next restartpoint silently spanned
  image-less WAL.  Replayed checkpoint records declaring
  full_page_writes = off now advance lastFpwDisableRecPtr too, and the
  same helper warns once when a server replays image-less WAL without
  running a double write buffer of its own.

* The do_pg_backup_start/stop refusals name io_torn_pages_protection
  and the workable paths instead of a full_page_writes hint that this
  mode ignores; 005 tests the refusal.  Mode "off" logs its state at
  startup.  pg_dwb is documented in protocol.sgml, backup.sgml and
  storage.sgml.

Test hardening: 005 fits the runtime budget, asserts minRecoveryPoint
advance from replay-driven flushes alone, verifies page contents, and
promotes with the replay pause still in effect so the backlog is real;
006 checks pg_waldump errors and matches the forced FPI by file node;
new 008_modes.pl pins mode "off", the legacy GUC under "full_pages"
and the SIGHUP no-op under "double_writes".

pg_rewind now supports a ring living behind a symlinked pg_dwb: the
target traversal follows the link so the exclusion-driven removal wipes
the ring through it, the entry itself is never created, removed or
type-checked (the server recreates it lazily), and sync_pgdata() syncs
the linked directory like a symlinked pg_wal, making the wipe durable.
The source's link is deliberately not followed: its ring is never used,
so a broken link there must not fail the rewind.

A new up-front checkTargetDwb() runs before the target is touched in
any way -- in particular before the single-user recovery run -- and
rejects garbage the file-list traversal cannot see: a non-directory
entry, a symlink not pointing at an accessible directory, or anything
but regular files inside the flat ring.

A restart transition into double_writes emits no XLOG_FPW_CHANGE, so
the new 009 test pins the replayed-checkpoint tracking end to end: an
online backup opened on a standby before the transition must fail
pg_backup_stop(), and a standby without a ring of its own warns exactly
once per startup.  007 grew refusal scenarios for every garbage pg_dwb
layout, asserted against a crashed target via pg_controldata to prove
the refusal precedes recovery.

The replace-guard in DWBOpenNewBatch computes staleness into a flag
instead of duplicating the release-and-return sequence per branch.
decide_file_action() drops the refusal of a regular-file pg_dwb on the
source: the source's ring is never read or copied, so the check
protected nothing (the target side is covered by checkTargetDwb()).
The rewind test hoists the six copies of the pg_rewind invocation into
one array.  No behavior change on any path a server can reach.

Before WAL replay, DWBStartup now runs an eager apply-pass over the ring
unless it was cleanly closed: candidate slots (valid batch header,
meta_crc, current generation, image_crc, not ABORTED) are deduplicated
per page keeping the highest LSN, and a data page is rewritten from its
slot copy when it fails verification or is older than the copy; repaired
forks are fsynced before the generation bump.  This is the only repair
path, and it covers pages replay never reads, such as hint-bit-only
pages logged as XLOG_FPI_FOR_HINT without an image.

The ring's control file gains a RING_CLEAN marker, written at the tail
of a clean shutdown once the ring is fully retired and cleared when the
ring reopens.  The apply-pass keys on pg_control OR the marker: a
standby's shutdown restartpoint can be skipped entirely, leaving segment
fsyncs pending behind a clean pg_control.  The same marker guards mode
downgrades: with an uncleanly closed ring, a start under full_pages or
off is refused until one clean double_writes run applies it.

A start from a restored base backup (backup_label present, or
backupStartPoint still set after a crash mid-backup-recovery) never
applies a ring shipped by a third-party backup tool: the generation and
LSN defences both pass honestly there, and an apply would push pages
from the backup's future into a PITR target.  The ring contents are
discarded and recreated cold, in the non-DWB modes too.  A geometry
change now applies the old ring first and recreates it under the new
geometry instead of refusing to start.

io_torn_pages_protection is recorded in pg_control and in
XLOG_PARAMETER_CHANGE, like wal_level: a server expecting full-page
protection refuses to replay WAL generated without page images
(CheckRequiredParameterValues FATAL, replacing the once-per-startup
WARNING), the standby backup guards name the primary's actual mode, and
pg_rewind reads a live source's mode from its pg_control up front,
before ensureCleanShutdown can touch the target.  On a crashed standby
the apply-pass raises minRecoveryPoint to the highest applied LSN as a
belt-and-braces enforcement of what the write path already guarantees.

Tests: new t/010_recovery.pl (torn hint page, stale-but-valid page
repaired by LSN, idempotent re-apply, clean-start skip, past-generation
slot never applied); 009 re-pointed at the legacy full_page_writes=off
transition plus the incompatible-standby FATAL; 006 plants a foreign
ring into a restore; 007 rewinds a crashed target through the
single-user run; 008 covers the downgrade guard; 001 the geometry
recreate.

…w-up)

Key the apply-pass decision on the RING_CLEAN marker alone and drop the
unclean_start parameter of DWBStartup.  The marker is the exact
certificate: it is set only after full retirement and cleared before the
ring reopens, while pg_control diverges from the ring in both directions.
Keying on pg_control let a crash under an interim full_pages/off run
(which touches neither the marker nor the generation) re-arm a fully
retired ring: its slots still matched the current generation, and the
pass would resurrect ancient page images over blocks torn long after the
ring was closed, turning a loud checksum failure into silent corruption.

Close the remaining error-path holes around the pass:

- Fail closed when backup_label cannot be probed: any errno other than
  ENOENT is now FATAL instead of reading as "not restoring a backup",
  which would have applied a ring shipped inside a base backup.
- Skip candidates whose on-disk page is new (empty header).  A zeroed
  header proves the covered write's first sector never landed on a block
  that never held an initialized page, so replay recreates it; repairing
  would also let a pre-truncate slot image resurrect on a re-extended
  zero page whose LSN 0 loses the staleness comparison.
- Make DWBWipeRing remove the control file first, durably, and let the
  cold-create path sweep leftovers: a crash mid-wipe used to leave a
  readable control beside missing batch files, and every retry then
  died on the ENOENT until manual intervention.
- Re-verify the slot image CRC after the repair loop's second read;
  divergent reads mean failing storage and abort startup instead of
  writing unverified bytes over a data page.
- Cover DB_SHUTDOWNED_IN_RECOVERY in the minRecoveryPoint raise: the
  pass also runs on a cleanly stopped standby with an unretired ring.
- Refuse an unreadable pg_dwb/control in full_pages/off modes with the
  downgrade guard's message and removal hint instead of a bare
  low-level FATAL that named no way out.
- Warn when crash recovery replays WAL generated under
  io_torn_pages_protection=off with a different local mode: pages torn
  by that crash cannot be repaired by any local mechanism.

Place io_torn_pages_protection next to wal_level in ControlFileData and
xl_parameter_change (both formats were already bumped on this branch),
deduplicate applied forks with a hash table, reuse DWBBatchFilePath
instead of a second spelling of the batch path, log the ring wipe in
non-DWB restore starts, use ereport(LOG) for the minRecoveryPoint raise,
and pin down invariants at their definition sites: the enum values are
on-disk facts and must not be renumbered, batch_id monotonicity within a
run is what makes the equal-LSN tie-break valid, and the flags field
fills a former CRC-covered padding hole, which is why version-1 control
files read back compatibly.

New and extended tests: t/011_geometry_recovery.pl pins that a crashed
ring is applied with its recorded geometry before being recreated under
new GUCs; t/010 pins the marker-only trigger (clean pg_control, unclean
ring) and the dropped-relation skip; t/008 pins that reopening the ring
re-arms the downgrade guard and that a corrupt control refuses non-ring
modes with the hinted recipe actually working; t/006 pins the planted
ring wipe under full_pages; t/005 pins a torn standby page repaired from
the standby's own ring.

The verification round over the previous commit confirmed every original
finding fixed and surfaced a handful of new ones, all closed here.

Re-bump PG_CONTROL_VERSION (1802) and XLOG_PAGE_MAGIC (0xD11A): the
previous commit moved io_torn_pages_protection next to wal_level in
ControlFileData and xl_parameter_change without changing the version
constants it had already claimed, so a data directory initialized on the
previous commit would be reinterpreted field-by-field with a matching
CRC and no complaint.

Limit the crash-under-"off" warning to servers whose crashed run owned
the pg_control mode field: on a standby the field describes the primary,
and a local double_writes standby of an "off" primary would have drawn
the warning on every crash while its own ring repaired the pages the
message declared unrepairable.

Make DWBWipeRing report whether it removed anything and log the
"discarding ring contents" message only then — a restored base backup
normally ships pg_dwb/ empty, and every ordinary restore start claimed
to have discarded contents that never existed.  The empty-directory
early return also makes the second wipe of a double_writes restore a
no-op.

Keep a too-new ring format version on its own FATAL instead of folding
it into the corrupt-control refusal: that ring is intact and the
"remove pg_dwb" hint would invite discarding it.  The remaining corrupt
paths now log the specific low-level cause (errno, short read, bad
checksum) before the caller's summary FATAL, and the previously
unchecked close in the short-read branch is reported too.

Comment accuracy, per the re-review: the batch_id tie-break is a
deterministic pick among hint-bit-equivalent copies, not a strict
later-copy guarantee (ids are assigned at batch open and two writer
classes can invert the order); the PageIsNew-skip rationale now covers
the all-zero staged image FlushBuffer can produce; the RING_CLEAN
contract states that any future ring-opening path must clear the marker
in the same control write; DWBWipeRing's header names all its callers;
the file header no longer claims non-ring modes never touch the ring.

New tests: t/008 pins the suppressing direction of the marker keying —
a crash under an interim full_pages run must not re-arm the apply-pass —
and the warning after a crash under "off"; t/010 pins that an all-zero
on-disk page is never repaired from a slot, bytewise.

DWBReadControlFile duplicated every failure as a LOG-when-tolerated /
FATAL-otherwise pair; a single ereport per failure with a variable
elevel says the same thing in half the lines.

The two restored-backup wipe branches of DWBStartup were byte-identical;
hoist one conditional wipe above the mode split.  This also discards a
shipped ring before the data-checksums check rather than after — an
inconsequential reordering, since such a ring is doomed in every mode.

The batch_id tie-break story was told in full at three sites, and the
last review round had to correct all three in lockstep; the dedup
comment in DWBApplyPass keeps the full argument, the two field comments
now just point there while retaining the local fact (assignment at batch
open, monotonic per run).

The raw block I/O helpers were copied into three TAP files; they now
live in t/DWBTest.pm (following pg_rewind's RewindTest.pm precedent).

Pin down the apply-pass behaviours the runtime write path cannot be
steered into:

* New test_dwb_craft_batch() writes a synthetic single-slot batch file
  directly, taking geometry and generation from the ring control; the
  image is the block's on-disk content with a chosen LSN, a marker in
  the page hole and a recomputed checksum, so an applied image remains
  a valid page.  012_apply_crafted.pl uses it to pin the dedup
  comparator - the higher LSN wins, and an equal-LSN tie goes to the
  higher batch_id against scan order - and the standby minRecoveryPoint
  raise, crafting a slot LSN inside the received-but-unreplayed window
  held open by pg_wal_replay_pause.

* 013_backup_start_point.pl pins the backupStartPoint arm of the
  restored-backup detection end to end: a low-level copy taken inside
  an open backup window lacks the backup-end WAL, so recovery from it
  fails deterministically; the first start consumes backup_label, the
  second start runs on backupStartPoint alone, and both must discard
  the ring instead of applying it.

* 014_pg_upgrade.pl runs a same-version pg_upgrade from a double_writes
  cluster: nothing of pg_dwb/ transfers, and the upgraded cluster
  cold-starts a ring of its own.

* New test_dwb_set_control_min_version() rewrites the ring control with
  a chosen min_version and a matching CRC; 008_modes.pl asserts that
  the format-version refusal names the version gap rather than the
  corrupt-ring removal advice, and that leftovers of an interrupted
  wipe (batch files behind a missing control) are swept by the
  cold-create path.

* 009_fpw_transition.pl asserts that a crashed double_writes standby of
  an "off" primary restarts without the crash-under-off warning, and
  006_backup.pl that an ordinary restore does not claim to discard the
  empty pg_dwb directory it ships.

config.sgml gains io_torn_pages_protection and the dwb_* parameters,
ordered as in postgresql.conf.sample, plus a note that full_page_writes
is consulted only in full_pages mode.  wal.sgml describes the double
write buffer next to the discussion of partial page writes.  backup.sgml
notes that an active base backup forces page images back into WAL under
double_writes; pg_basebackup's standby-backup limitations name the
full_pages requirement on the primary; pg_rewind documents the
full_pages requirement for a live source and the fate of pg_dwb during
a rewind.  monitoring.sgml adds the dwb object of pg_stat_io.

The double_writes documentation promised that WAL carries no full page
images at all; operations registering a block with REGBUF_FORCE_IMAGE
still log one regardless of doPageWrites, so speak of the automatic
first-modification-after-checkpoint images instead, in config.sgml,
wal.sgml and the pg_basebackup standby-backup limitation.  The ring
also covers only permanent relations, so say "every permanent data
page".  The pg_stat_io intro in monitoring.sgml now mentions the double
write buffer next to relations and WAL.

013_backup_start_point.pl asserted the absence of an apply-pass only
after the second failed start; add the same negative check against the
first start's log window.

pgindent rewraps two comments in bgwriter.c and postmaster.c that fell
short of the 78-column margin.

perltidy reformats the 14 test_dwb TAP tests -- argument wrapping, paren
tightness and continuation indentation.  Run with version 20230309, the
one pinned by src/tools/pgindent/README.

perlcritic flagged the sysseek() calls in 001_dwb.pl as ignoring their
return value.  The defined-or guard does check it, but
RequireCheckedSyscalls only recognizes "or die", which is the form used
throughout the rest of the tree, so switch to it.

Formatting only; the test_dwb suite (261 tests) still passes.

The 6-point grid on the SF75K stand showed two structural sink defects:
the checkpointer degenerated to one-slot batches (one fdatasync per page
via the lone-writer seal), and at >= 2700 connections it starved outright
because the one-sided eviction reserve never let the background class
open a batch while evicting backends kept the free count at the throttle
line.

BufferSync now collects permanent buffers into bins of up to
dwb_batch_pages (capped at 64 by the content-lock budget) and flushes
each bin through the DWB as one batch: a non-blocking gather (conditional
content lock plus nowait StartBufferIO; contended buffers fall back to
the per-page path), one WAL flush, one staged batch with a single
fdatasync, then the data-file writes.  New DWBStagePageWriteNoWait and
DWBWaitStagedWrites compose the existing write-path primitives for
vectored callers.

The FREE-batch policy becomes sliced: the bottom DWB_BG_RESERVE batches
are for the background class only, the middle DWB_EVICT_RESERVE slice
for eviction only, everything above is shared.  A leave-some-behind rule
alone cannot end the starvation: under saturation the free count hovers
at the greedier class's throttle line and the background stream never
reaches a batch.

test_dwb: 001 covers the sliced boundaries including the background lane
at free=1; 003 fills the background lane before the checkpointer stall
scenario; 010/011 accept the larger candidate sets of bin-written rings;
new 015_vectored_flush.pl pins the multi-slot batch ratio via pg_stat_io
and repairs a torn page written by the vectored path.

…lush

The bin gather trusted the caller's unlocked BM_PERMANENT pre-check, with
only an Assert behind it: a buffer recycled for an unlogged page between
the pre-check and the gather would have been staged into the double write
buffer and its fake LSN fed to XLogFlush.  Re-check under the buffer
header lock and route non-permanent buffers to the per-page fallback,
whose FlushBuffer skips both the WAL flush and the DWB for them.  The
deterministic unlogged paths were already pinned by t/002 (a shutdown
checkpoint's unlogged buffers never enter the ring); the recycle window
itself is instruction-scale and remains guard-only.

…e 5)

Under thousands of concurrent writers the single cv_free_batch condition
variable collapsed: every batch SEAL pushed all same-class writers into
DWBOpenNewBatch at once, each of them had to win one of the four staging
buffers just to discover that somebody else had already opened the next
batch, and every staging release or batch retirement broadcast to every
waiter.  A profile at 5000 connections showed ~74% of a 104-core machine
spinning in s_lock on the condition variable's spinlock, 817K context
switches per second, and the retire sink idle.

Restructure the wait path:

- cv_free_batch becomes cv_want_batch[writer class]: one queue per class,
  used by both the staging-pool and the ring-space waits (both conditions
  are re-checked in the common DWBOpenNewBatch loop).  Splitting by class
  makes a wake-up impossible to lose across the class boundary, where the
  sliced reserves may forbid the woken class to open a batch.

- DWBOpenNewBatch starts with a lock-free staleness check (the same
  SEAL-bit/class-bit test, authoritatively repeated under
  DWBRingOpenLock), so the herd that piles in after a SEAL returns to
  slot reservation without touching the staging pool or waking anyone.
  The staging reservation itself is now non-blocking; an empty pool is
  waited out in the same outer loop.

- All wake-ups are targeted signals instead of broadcasts: a successful
  opener wakes up to batch_pages - 1 same-class waiters (the number of
  slots joiners can still take), and a staging release or a batch
  retirement wakes one would-be opener per class.  The 1s sleep timeout
  stays as the lost-wakeup backstop, and the stall escalation clock is
  unchanged.

The open-batch sharding idea (K open batches per class) stays shelved:
the same profile shows the intra-batch rendezvous is not hot (DWBRingOpen
waits ~0, coverage/fsync waits in the single digits out of 5000 waiters).

Suite: test_dwb 15 files / 269 tests, core regress 231, concurrency
tests looped 3x.

With every DWBStagingRelease signalling cv_want_batch, a full ring turned
the paced 1s waits into a busy rotation: a woken prober re-signalled the
queue when it returned its unused staging buffer, handing the wake token
to the next waiter (or straight back to itself — a timeout wake-up leaves
the process queued on the condition variable, so its own signal can pop
it), and the token circulated through DWBRingOpenLock acquisitions and
ring scans indefinitely while nothing had changed.

Make DWBStagingRelease silent and wake explicitly at the real capacity
transitions only: a leader finishing its image pwrite (the buffer can
serve the next batch), a batch returning to FREE, and a fresh batch
opening.  A probe-acquired buffer bouncing back unused wakes nobody; the
1s sleep timeout remains the backstop for the rare sleeper that raced
against the last buffer.

Add a shmem counter of wait-loop iterations that went to sleep
(ring_wait_retries) with a test_dwb reader, and pin the pacing in the
003 real-clock scenario: a victim parked on an unchanged full ring for
~1s must accrue a handful of retries, not the thousands a rotating wake
token produces.

Suite: test_dwb 15 files / 271 tests, 003 looped 5x.

Two sink-side costs measured on the 104-core stand after the wakeup-storm
fix (2700 connections, 300s checkpoints):

- ~51% of all CPU went to LWLock traffic under DWBRetireSweep: every
  writer parked on a full ring ran the self-help sweep before sleeping,
  and hundreds of concurrent sweepers hammered the per-batch publish
  locks and the segment hash (907 backends queued on DWBPublish) while
  losing almost every fsync claim to whoever got there first.  Gate the
  self-help with a new DWBSelfSweep LWLock taken conditionally: one
  sweeper sweeps, trylock losers go straight to sleep and are woken by
  the winner's frees through cv_want_batch.  An LWLock rather than an
  atomic flag keeps the gate error-safe (released by the unwind).

- The bgwriter emitted 178.7K single-slot batches in 900s — one full
  batch fdatasync per scattered LRU page (199/s) and ~12% of the ring's
  batch turnover for ~0.4% of the pages.  Route the LRU scan through the
  same bin machinery as the checkpoint flush: BgSyncPeekBuffer (the
  check half of SyncOneBuffer, same skip-recently-used semantics)
  classifies buffers, would-write candidates collect into a bin and
  flush as one batch via FlushBufferBin (renamed from FlushCkptBufferBin,
  with the bin cap now DWB_FLUSH_BIN_MAX), preserving the
  bgwriter_lru_maxpages budget and the reusable-buffers estimator.
  A buffer that changes between the peek and the flush is re-checked
  under the header lock inside the bin, exactly as for the checkpointer.

New test t/016_bgwriter_bin.pl pins the bgwriter batching through
pg_stat_io (average batch >= 4 slots under UPDATE passes through a small
buffer pool).

Suite: test_dwb 16 files / 272 tests, 016 looped 5x, core regress
231/231.

Review follow-ups to the sweep-gate / bgwriter-bin commit:

- New 003 scenario proves the single-sweeper property end to end: a
  dwb-self-sweep injection point sits inside the trylock-guarded section,
  so a process can only park there after winning DWBSelfSweepLock.  With
  the ring exhausted and two stalled writers, the first victim parks at
  the point while the second one goes to sleep in the ring wait — the
  sleep proves it took the trylock-failed path, and pg_stat_activity
  shows exactly one process at the point.  The point is detached before
  the wakeup: the winner re-enters the gate on its retry loop, and with
  the point still attached it would park again with no wakeup left to
  release it.  The scenario then lets both victims finish: the ring is
  not required to go idle while they still write through it.

- FlushBufferBin's header no longer claims every caller pre-filters
  BM_PERMANENT (the bgwriter's peek deliberately does not) and states
  explicitly that pin and usage counts are not re-checked past the
  callers' pick — the same benign race the per-page paths have.
  BgSyncPeekBuffer's comment lists exactly what the bin re-checks.

- 016 resets shared io statistics after the data load so only the
  bgwriter's own writes enter the average, and polls between UPDATE
  passes instead of sampling once per pass.

Suite: test_dwb 16 files / 275 tests, 003+016 looped 5x, pgindent and
perltidy clean.

A shared random workload touches nearly every segment of a large table
between retire rounds, so the per-segment protocol pays hundreds of
fdatasync calls per sweep and a batch waits for the sweep to visit all
of its segments before it can be freed.  The new dwb_retire_sync_method
(default syncfs where available) makes a retire round issue one syncfs()
per file system holding data files and then free every batch that was
already RETIRING when the round began: their data-file writes preceded
the syncfs, so they are durable.  The per-segment path stays as the
fallback and keeps serving the checkpointer piggyback and the OOM retire
in both modes.

Also add per-class, per-reason seal counters (overflow, lone-writer,
waiter timeout, worker timeout, bin flush, forced) with slot sums,
exposed through test_dwb_seal_stats(): client batches average half-full
on the perf stand and the counters attribute that turnover to its
trigger.

New TAP test 017 drives a workload through a worker running syncfs
rounds with fsync on and crash-checks the result; 002 asserts the
no-pool lone-seal accounting, 004 pins the fsync method to keep the
per-segment sweep covered, and the regress test pins the deterministic
overflow/forced counts.

Every retire worker wakes on the same cv_retire_wake broadcast, so with
a pool larger than one the workers would all run the same global
syncfs() round back to back, multiplying whole-file-system syncs for no
benefit; the ring-full self-help could pile on top.  Guard the round
with LWLockConditionalAcquire on the new DWBSyncfsRoundLock: one process
collects and syncs, losers return at once and are woken again by the
winner's frees or the next publication.  The batch collect runs under
the lock, so a loser can never free batches some other round's syncfs
did not cover.

017 now runs two retire workers and pins the single-admission property
deterministically: a dwb-syncfs-round injection point inside the gate
parks the winner, the loser must fall back asleep in its main loop, and
the resumed round must free a batch parked with test_dwb_park().  While
a process is parked inside the gate ALL wholesale retirement is frozen,
so the scenario stays ring-quiet — no eviction workload runs until the
point is detached (detach strictly before wakeup, as in 003).

Also reunite the "change requires restart" comment with
dwb_retire_workers in postgresql.conf.sample; the new SIGHUP parameter
had been inserted between them.

Seal accounting on the perf stand showed 54% of eviction batches sealed
by the lone-writer fast seal at 1.33 slots average, while overflow-sealed
batches carry exactly 64: under a dense concurrent stream the FIRST
writer of every freshly opened batch publishes within microseconds and
reaches the fsync wait while ref_count is still 1, so the fast seal
meant for sequential streams halves the ring into one-page batches and
doubles the batch-file fsync count.

Gate the fast seal on the class being quiet: every overflow seal stamps
the class's last-overflow timestamp (twice — at the seal win so
concurrent writers see the class as hot during the leader write, and
after the write so the window survives a slow batch fdatasync), and a
lone writer skips the fast seal while DWBClassIsHot sees the stamp as
younger than dwb_batch_timeout_ms.  A stamp from the future — a backward
system-clock step — reads as quiet, keeping the immediate seal instead
of taxing sequential streams until the clock catches up.  A wrongly
suppressed seal costs at most the window: the waiter's own timeout seal
fires after it in every mode, and the retire workers' force-seal backs
it up whenever a pool is configured.  Sequential streams see no overflow
seals and keep the immediate seal, as does the unconditional no-pool
seal in DWBStagePageWrite.

The regress test pins all three sides deterministically through the
seal counters: a quiet class fast-seals one staged page (lone +1); a
hot-window driver overflows a batch in the same backend and enters the
wait on the next batch's first slot microseconds later — the fast seal
must give way to the waiter's timeout seal (overflow +1, wait_timeout
+1, lone +0); and a planted future stamp must read as quiet through the
same DWBClassIsHot helper and keep the fast seal immediate.
dwb_batch_timeout_ms is raised to 200ms in the regress configuration so
the in-process stamp-to-check gap has a wide margin over the threshold
on slow machines.

…age 5)

Per-interval diagnostics of the tps saw showed a bistable latch: at the
pool's drain ceiling the bin queue runs at capacity, and the bgwriter's
fallback of flushing refused bins itself stalled its LRU scan behind
serial batch fsyncs.  The strategy clock hand then caught the scan
point, backends started evicting dirty buffers at full double write
buffer latency, and the queued hints went stale en masse — a state that
sustained itself until the tps sag let the scan break ahead again.

Remove the fallback: with an active cleaner pool the bgwriter writes no
data pages at all.  A bin refused by a full queue is kept in the (now
static) bin storage and the round ends early — scanning further ahead
would only produce bins nobody can drain — then the carried bin is
re-offered at the top of the next round, so a saturated pool is polled
at bgwriter_delay cadence and the scan resumes the instant a worker
frees queue space.  A disabled scan (bgwriter_lru_maxpages = 0) drops
the carried bin, and a budget shrunk below an accepted bin's size ends
the round with maxwritten_clean counted.  Pool-less mode is unchanged.

The enqueue now takes the queue lock unconditionally (the critical
section is one bin copy), so a refusal means exactly "queue full" and
the renamed deferred_bins counter is a pure saturation gauge.  The
queue capacity becomes a fixed 64 bins instead of scaling with the
worker count: it is a burst absorber, and even a full queue drains in
tens of milliseconds at observed pool rates.

The backpressure test scenario now pins the deferral contract instead:
a full queue grows the deferral counter while the bgwriter's own DWB
write count stays flat, a disabled scan stops the deferral stream and
feeds the drained queue nothing, and re-enabling the scan resumes the
feed.

With backend evictions absorbed by the cleaner pool, autovacuum workers
were left as the last degenerate ring writers: flushing dirty pages out
of their private ring strategy through the per-page path in a cold
eviction class, where the lone-writer fast seal fires for every page —
one batch and one ring fdatasync per page (142K one-slot batches per
900 s in the r14 verdict run, ~158 wasted syncs/s).

Autovacuum is a scheduled sequential writer, not a latency-critical
evictor, so classify its workers with the background stream.  The
class hotness gate then does the right thing in both regimes: under
load the background class is hot with the pool's bin batches, the lone
seal is suppressed and autovacuum pages ride those batches at their
fill; on a quiet system the class is cold and the immediate lone seal
keeps today's per-page latency.  The launcher and manual VACUUM stay
in the eviction class.

The new test drives a real autovacuum pass through its ring strategy:
the table is deleted from while autovacuum is held off per-table, a
clean restart empties shared buffers, and the pass then reads every
page through the ring and prunes it dirty, forcing ring-wrap flushes.
The walwriter is paced to flush aggressively because the vacuum ring
only reuses a dirty buffer whose WAL is already flushed.  The
background class must grow while the eviction class stays flat, and
the autovacuum worker's pg_stat_io ring writes must appear.

The post-promotion window check captures its start LSN with
pg_current_wal_lsn() while concurrent imageless FPI_FOR_HINT records
are still being inserted; the write position advances in whole pages,
so the captured LSN occasionally lands exactly on a WAL page boundary.
pg_waldump then skips the page header to the first whole record and
reports that with a benign informational line on stderr, which the
test treated as a failure.  Strip exactly that line before asserting
that stderr is empty; anything else on stderr still fails the test.

Caught by an instrumented 30-run loop of the full suite (2 hits, both
with the start LSN page-aligned); 30/30 clean with the fix.

With io_torn_pages_protection = double_writes the WAL stream carries no
full-page images and degenerates into a dense flow of small records, so
high-connection workloads hit contention on the eight insertion slots
long before the WAL device saturates.  Benchmarks of the double-write
path on a 104-thread machine at 2700 connections were measured with 32
insertion locks on both the patched and the reference builds; codify
that value.

The 2700-connection time series now shows the double-write build with
the checkpointer-yield change: the checkpoint-window dips are gone from
the DWB curve (worst 10 s sample 102.8K vs 98.6K before).

Assets for the primary/synchronous-standby comparison: throughput and
shipped WAL per client count, and the standby replay backlog over the
run.

A worker asked smgr for the relation's size on every request, and smgr
answers that question from its cache only for the startup process:
smgrnblocks_cached() returns nothing to anybody else, "due to lack of a
shared invalidation mechanism for changes in file size".  So every request
measured afresh, and measuring walks the segment chain from the beginning
after smgrexists() has closed it — a thousand file opens on a terabyte
relation.

On the primary-to-sync-standby stand that was the whole pool: twelve
workers each burning a core at 273k file opens a second, 4.6 ms of CPU per
request and nothing left for reading pages.  The ring stayed full, three
quarters of the blocks the prefetcher offered were refused for want of a
slot, and replay collected almost nothing — the standby fell behind exactly
as it did with no pool at all.

The pool does have the invalidation mechanism smgr lacks: the drop epoch,
bumped under ReplayWarmReadLock whenever a relation or a database is about
to lose its files.  A size measured within an epoch can therefore only be
too small, never too large, so a worker keeps its own small direct-mapped
table of them: the first request for a fork pays for the existence check
and the measurement, a block past a remembered end pays for measuring
again — the relation may simply have been extended — and everything else is
a comparison.

The same run then reads 58k pages a second in the workers, hands replay
98.3% of what it publishes, and takes the standby's replay lag from a
median of 63 seconds to 9 milliseconds, with the startup process reading
40 thousand pages over the run instead of 43.5 million.

Throughput per socket count and the two-socket point over its run, DWB
with the replay warm pool against vanilla, primary and standby on
separate hosts across a 100 GbE link.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013tqXDnyVLb628yQ14HaznA

Replay signalled the pool once per published block, which is a kill(2)
each time, and it decided page residency itself before publishing, which
is a buffer-table lookup each time.  Together those were 28 % of the
process that applies the WAL, as much as applying it.

The publisher now signals only when nobody is searching the ring, and a
worker that leaves the search hands the ring on in its place; scanners,
pending and sleepers are what the two sides read to agree on that.  A
worker that dies hands it on from its exit path, whether it was searching
or asleep.  Residency moves into the worker, so every block reference is
published rather than only the misses, and the worker counts the hit or
the read for pg_stat_recovery_prefetch.

Publishing every reference put five times more traffic through the size
check each request makes, which turned a latent defect in that check into
a fatal one.  It kept its own sixteen-entry cache indexed by the low bits
of the relation number, and relation numbers are handed out sequentially,
so two hot relations sixty-four apart share a row for good.  Its miss path
asked smgrexists(), which closes the whole fork outside the startup
process, and the smgrnblocks() behind it then reopened the entire segment
chain: one worker made 572k file opens against a single page read in
twelve seconds.

The size now comes from smgr_cached_nblocks on the SMgrRelation the worker
already opens for the read.  That is keyed by the whole relation identity,
has no fixed size and no eviction policy to get wrong, and is cleared by
the smgrreleaseall() this pool already runs when replay tells it that
files have gone.  smgrexists() stays for the one cold path that has to
tell a vanished relation from a short one.

The ring bounds how far ahead of replay the pool looks, and since every
block reference now takes a slot rather than only the misses, the shipped
256 buys a quarter of the read-ahead it used to.  Four points on a
two-host pair, one after another so the pair ages equally between them,
600 s of 750-client pgbench each against a synchronous standby:

  ring   applied     pool CPU   tps
   256   38.8 MB/s   5.9 cores  136.0k
   512   47.8 MB/s   9.7 cores  141.2k
  1024   47.0 MB/s  14.3 cores  137.1k
  2048   42.7 MB/s  13.3 cores  139.0k

512 is where it stops paying: 1024 buys nothing for half again as much
pool CPU, and at 1024 the startup process's wait for pages falls from
15.3 % to 10.3 % without moving throughput, which says the wall past this
point is the single replay process itself and not the window.

Also adds the scenario for the race the exit-path hand-off exists to
close: the worker that dies is the one the publisher has just woken.  A
signal goes to the head of the wait list and takes it off, so a head on
its way out consumes the only wakeup.  The head is made certain by
replacing one of two workers — the list is joined at the tail — and the
race is held open by stopping that process, which keeps it registered and
asleep where an injection point could not: preparing to sleep on the
point's own variable cancels the registration on the pool's.  The
evidence is which worker ends up holding the slot, not that the slot was
served, because the replacement of the dead worker would serve it either
way.

It holds a worker still with SIGSTOP to keep it registered on the wait
list while the publisher signals, and Windows has no equivalent of that.
019_replslot_limit.pl steps around the same limitation.

Three assets for the pull request's benchmark comment: what each
replay_warm_queue_size buys the standby and costs the pool, and the
primary's throughput and latency over each of the four 600 s runs.

smgrdounlinkall and smgrtruncate call XLogWarmDropBegin and XLogWarmDropEnd
without a declaration in scope, which the compiler accepts with a warning and
a guessed prototype.  Include the header that declares them.

test_dwb_checkpoint_pending reads and writes a block through smgr, which
may reach the file with direct I/O and requires a buffer aligned for it.
The buffer was declared with block alignment only, and an assert build
dies on the first call -- the standby is killed by the assertion in
buffers_to_iovec and the test hangs waiting for it, which takes the
whole tree's check-world down with it.

Give that one buffer PGIOAlignedBlock.  The other page buffers here are
read and written through this test's own descriptors, where block
alignment is all that is asked for, and the comment says which is which.

Nothing outside the test needs changing: every buffer the double write
buffer itself hands to smgr is allocated with palloc_aligned, its
staging area is aligned where it is carved out of shared memory, and its
one raw write opens the file without direct I/O.